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Problem 

Current day spacecraft are complex ma- 
chines and those on the drawing boards are 
increasingly more sophisticated and 
broader in scope. Gone are the days when a 
single engineer could fully grasp the intri- 
cacies of an entire satellite. Note that the 
reoently launched Galileo spacecraft has 
several processors on-board the vehicle 1 1 1. 
This fact, coupled with the increasing 
power of computing hardware and software 
tools and techniques, has introduced the 
possibility of realistic simulations being 
used for product definition, design, manu- 
facture. and. even, performance analysis. 
The Strategic Defense Initiative Office 
(SDIO) is convinced of simulation capabili- 
ties since it has funded the National Test Bed 
(NTB) facility to evaluate the performance 
of all facets of the ‘Star Wars* concept. 

Due to heated competition for the develop- 
ment and delivery of satellites, there is an 
increased reliance on simulation of compo- 
nents. subsystems, systems, and entire 
constellations of spacecraft. Given the wide 
variety of configurations and purposes of 
these satellites, flexible and convenient 
means for generating study and engineer- 
ing data are necessary 12-41. Monolithic 
simulations have become unwieldy and ex- 
pensive to maintain. Configurable tools that 
can be quickly and accurately constructed 
are required. Rapid prototyping techniques 
have become more accepted within the 
aerospace industry for the production of 
deliverable software and also as a means to 


manage the software process [51 


We were motivated to define and build a so- 
phisticated satellite simulation capability 
for the evaluation of a satellite operations ^ 
automated environment called IntelliST AR" 
[6. 7J. This architecture, and associated 
prototype, addresses the entire spacecraft 
operations cycle including pla nn i n g, 
scheduling, task execution, and analysis. It 
is aimed at increasing the autonomous 
capability of current and future spacecraft. 
It utilizes advanced software techniques to 
address incomplete and conflicting data for 
making decisions. It also encompasses 
critical response time requirements, com- 
plex relationships among multiple systems, 
and dynamically changing objectives. 

Given the extreme scope of activities that 
are targeted, a sophisticated, flexible, and 
dynamic simulation environment was re- 
quired to drive this prototype In particular 
the derived requirements for evaluating the 
IntelliST AR" prototype include: 

• provide realistic and dynamic envi- 
ronment 

• easily reconfigurable 

• multiple levels of fidelity 

The overriding need of IntelliST AR~ was a 
means for providing a valid evaluation of 
the concept (see Figure 1 ). This evaluation 
was planned to be accomplished through 
the injection of various scenarios describ- 
ing mission and behavior types for the 
spacecraft to be controlled. Given this 
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stimulus, the lntelliSTAR’" prototype pro- 
vides measures of the plan and its status to 
satisfy the objectives for the satellite mis- 
sion. 

Approach 

The testbed approach to simulation has 
risen to the top of the list of options due to 
the following attributes: 

• flexibility to easily configure based 
on unique customer requirements 

• modularity of the simulation com- 
ponents to allow the testing of 
portions of the overall system or 
varying degrees of fidelity for 
portions within the same simula- 
tion 

• interoperability through the use of 
consistent user and integrator 
interfaces for reduced training. 


Side benefits include the centralized storage 
and accumulation of metrics and related in- 
formation of the simulation capabilities and 
past usage of the testbed. 

Our approach to the development, utiliza- 
tion. and maintenance of a sophisticated 
satellite simulation testbed is the use of 
rapid prototyping and knowledge-based 
techniques coordinated with the use of 
existing simulation and communication 
resources. An architecture has been de- 
fined that provides the following attributes 
for a spacecraft simulation that addresses 
autonomy, surveillance, and survivability 
capabilities (see Figure 2): 

• integrating architecture that sup- 
ports the expansion of capabilities 
and resouroes 

• hi gh -level user interface for speci- 
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fying simulation requirements and 
features in the form of a modelling 
language 

• automated translator from the 
modelling language to CLIPS code 
which can be executed 

• separability of generic spacecraft 
features from specialized compo- 
nents. subsystems, and payloads 

• interface to an existing survivabil- 
ity simulation 

• interface to an existing intelligent 
satellite operations framework 

• interface to a graphical user inter- 
face 


Architecture DeacrtPtto D 

We are using CLIPS as our basic program- 
ming language to create the modelling 
language, language translator, and simula- 
tion itself. The modelling language allows 
an engineer to specify the behavior of a 
system or subsystem in high-level terms 
that could be directly derived from specifi- 
cations. The translator takes the modelling 
language constructs, verifies their consis- 
tency. and creates CLIPS knowledge bases 
which can be executed. The simulation uses 
the CLIPS forward -chaining mechanism as 
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the driving force behind a system that is 
scalable to real-time events. Time can be 
specified directly or used in relative terms 
to compress or expand time to meet user 
requirements. 


required states. Side effects of component 
actions are relied upon heavily on space- 
craft These factors closely match the ad- 
vantages of a system built with CLIPS 


Satellite Modelling Language (SML) 

The modelling language was created to 
provide a higher level interface to the 
identified end-user, a spacecraft design 
engineer. This interface allows the engi- 
neer to input requirements and features in 
a format which is familiar. This promotes a 
more rapid acceptance and utilization of the 
testbed resource resulting in increased 
productivity and the exploration of a larger 
number of engineering options. 

SML provides context-relevant and English- 
like lang uage constructs to the spacecraft 
engineer. Through these constructs, the 
capability to describe events and timing is 
provided. This is accomplished through the 
use of three main structure types: templates, 
objects, and rules. Templates define con- 
glomerations of objects, 
objects relate to physical 
or functional entities, and 
rules describe the behav- 
ior of the objects for 
various conditions. 


Modelling language tranalator 

The modelling language translator accepts 
the simulation specification from the engi- 
neer and converts it into CLIPS knowledge 
bases which can be executed (refer to Fig- 
ure 3). This circumvents the need for the 
spacecraft engineer to become familiar 
with a new, and probably very different, 
software language. Also, since the CLIPS 
simulation code is automatically generated, 
the proper syntax and semantics are main- 
tained within the knowledge bases CLIPS is 
being applied in a manner much like an in- 
formation compiler. 

The translator acoepts the SML constructs 
and converts them into CLIPS-acceptable 
syntax. Templates and objects are converted 
to facts while behavior rules translate into 
CLIPS rules. The CLIPS rules handle all the 


The simulation itself uses 
CLIPS' forward -chaining 
technique to create a 
reactive and dynamic 
model of a spacecraft in 
its orbiting environment. 
Since spacecraft typically 
operate in a data- and 
situation-driven environ- 
ment, CLIPS is a perfect 
match. Processes on a 
satellite are usually in- 
voked on either a time or 
event basis. The stimuli 
cascade through many de- 
vices and components to 
achieve the necessary and 
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b ookke eping involved with the behavior 
such as retracting facts after they are no 
longer required and asserting the pertinent 
facts. 

The translator permits the incremental con- 
struction of a complete simulation capabil- 
ity. In practice, the modules are aligned 
with the subsystem designs. For instance, 
the Thermal Control Subsystem (TCS) tem- 
plates. objects, and behavior rules are all 
defined within a single file. The translator 
maintains a list of all possible constructs 
and allows the linking of these in any man- 
ner specified by the user. The linking pro- 
cedure also adds the executive timing con- 
trol to the executable simulation. 


Satellite simulation 

The satellite simulation generation method- 
ology is represented in Figure 4. Two paral- 
lel development paths have been identified 
for the creation of a realistic and dynamic 
evaluation environment for the IntelliS- 
TAR" prototype. One path concentrates on 


"Black box testing is not tut al- 
ternative to white box tech- 
niques. It is. rather, a comple- 
mentary approach that is likely 
to uncover a different class of* 
errors than white box methods. " 

[ 8 ] 

Behavioral models permit the description of 
the inputs and outputs of a function (or 
process or subsystem or _.) These models 
permit an empirical or high-level descrip- 
tion of an entity. These models can be 
constructed quickly with readily available 
information and allow various levels of de- 
tail. 

Functional models require an extensive 
evaluation of the theories and principles 
behind the operation of an entity. These 
models result from the classical design 
phase of an engineering process. Func- 
tional models have typically been developed 
in a monolithic mode. Good examples of 
functional model implementations are the 
current Computational Fluid Dynamics (CFD) 
codes being constructed. 



the creation of behavioral models while the 
other generates functional simulation 
capabilities. Behavioral models take the 
■black box' approach to testing Functional 
models are analogous to the “white box' ap- 
proach. This approach is justified by re- 
marks such as the following: 


The combination of these two simulation 
methods allows the generation of realistic 
environments quickly while not negating 
the growth path to more robust and in- 
depth simulation. In fart, the overall evalu- 
ation architecture permits the injection of 
models of varying fidelity levels into the 
same simulation. Behavioral and functional 
model can co-exist in the architecture. This 
provides a flexible medium for testing of the 
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IntelliSTAR" prototype In addition, the 
evaluation environment is not strictly tai- 
lored to that prototype, but also permits the 
construction of any satellite models. 

The test architecture encourages a modular 
generation and management of its constitu- 
ent parts. A conscious design decision was 
made to make the generic satellite bus 
characteristics separable from the special- 
ized subsystems or payloads that comprise a 
spacecraft. By doing so. a generic capabil- 
ity for simulating spacecraft was created. 
This model will continue to evolve and the 
available “library" of models will ino-ease 
as this effort proceeds. In fact, a major 
satellite effort at our division is contemplat- 
ing the use of this capability because of the 
attractiveness of minimal cost to tailor the 
system for their purposes. Our research can 
continue in parallel with this satellite ap- 
plication since models can be interchanged 
with little effort. 


Interfaces 

Three types of interfaces currently exist to 
the simulation environment. These include 
one to the IntelliSTAR” prototype, one to an 
existing survivability simulation, and the 
last to a user interface capability. The 
mechanism used for all three interfaces is 
the same; the results of a generic, distrib- 
uted prooess communications project are 
utilized. 

The interface to the IntelliSTAR" prototype 
is implemented to allow the evaluation of 
this satellite operations concept. The inter- 
actions between the prototype and the 
simulation are of two types; continuous and 
requested. The first type, continuous, con- 
tains the telemetry stream content from the 
spacecraft to the controlling entity (i.e.. 
IntelliSTAR") The information flow is 
handshaked between the two portions but 
the interface is not truly synchronous. 
IntelliSTAR" provides an execution time 
frame to the simulation and the simulation 
responds for that amount of time or at some 
smaller increment. The response time is 


solely determined by the simulation with 
only the upper bound specified by the 
prototype. 

The second type of interface to IntelliSTAR" 
is closer to being of the synchronous vari- 
ety. A request is made of the simulation for 
information and the simulator responds 
with the derived data The prototype may or 
may not wait for the results of its query 
before proceeding with its processing. 

An interface with an existing survivability 
simulation (SADEM - Satellite Attack and 
Defense Engagement Model) was con- 
structed. SADEM is constructed in an object- 
oriented and distributed environment. 
SADEM schedules a communications event to 
the spacecraft simulation at either a time or 
based on some condition. Currently, this 
interface is only one-way due to a limitation 
in the SADEM development environment. 

The last interface is to the user interface 
module. This interface allows the control 
and execution monitoring of the simulation. 
Individual measurements being generated 
by the simulator may be presented with 
user-specified limits. Graphical representa- 
tions of the data are allowed. 

Conclusions 

The simulation environment allows the in- 
tegration of several levels of fidelity and 
the configuration of many diverse compo- 
nents. The modelling language translator 
assures the consistent generation of syntac- 
tically and semantically correct spacecraft^ 
simulations. The “garbage in, garbage out" 
syndrome of many simulations is minimized 
through the active application of knowl- 
edge about spacecraft in general. This 
approach, and associated testbed develop- 
ment. enables the creation of a sophisticated 
and consistent satellite simulation environ- 
ment used for the design, manufacture, and 
analysis of satellites and their related op- 
erations environments. 
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